Reflect form validation error in title #509
Conversation
|
That’s a really interesting proposal 👍 |
|
When I use NVDA with Firefox, assuming the focus is set correctly, the h1 in the summary box is always read out first, not the page title. I tested it with the 2 examples in elements and it worked OK. |
|
I am not sure the W3C guidance means dynamically changing the page title or heading of the page you are currently on. The examples seem to me to be different pages, but that is only my interpretation of them. |
|
Universal Credit uses this approach. We prepend "Retry - " to the page title. We don't have client-side validation, so this is always through a ‘postback page refresh’. I don't have research to hand, but I believe the RNIB suggested we do this and screen readers users have found this useful. |
|
If this helps people I am all for it. I would avoid "error" or "mistake" because they imply blame. "Retry" or "Try again" would be better. It would be interesting to know what people put as the heaing in the summary box because there is no standard. I have seen "There is a problem" "There is a problem with the form", "This page has errors", and "There was a problem submitting the form". I am sure there are others. Tax credits uses "There is a problem" and it tested well with people. I would not want to mention "submitting" and "form" because it's jargon. |
|
@stevenaproctor is there any guidance from GDS or otherwise with regards to error messages? |
|
@adamsilver There is just the guidance in elements https://govuk-elements.herokuapp.com/errors/ and Dropbox https://paper.dropbox.com/doc/fifEJpOYMGjRy0lHTmthb At HMRC we are working on standardising errors for different types of form field for consistency. We will share whatever we come up. It would be good to have a single standard that includes:
We have just started this work so, hopefully, expect something in the next few weeks. |
|
That's awesome. We are looking at the exact same things :) Will let you
know what comes out of ours too.
…On 30 Jun 2017 7:40 pm, "Steven Proctor" ***@***.***> wrote:
@adamsilver <https://github.com/adamsilver> There is just the guidance in
elements https://govuk-elements.herokuapp.com/errors/ and Dropbox
https://paper.dropbox.com/doc/fifEJpOYMGjRy0lHTmthb
At HMRC we are working on standardising errors for different types of form
field for consistency. We will share whatever we come up. It would be good
to have a single standard that includes:
- location of the summary box (if you consider breadcrumbs, back
links, h1s)
- what the heading in the summary box should be
- different use cases and error message content
We have just started this work so, hopefully, expect something in the next
few weeks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#509 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACRKwhcV86fvymtfZEHNkpR88-6t0SVks5sJUEOgaJpZM4OJyR6>
.
|
|
Fair point about the language. I think it's probably best to change so it doesn't give any example but rather says to repeat the same words you use for the heading of the summary box. As people will (hopefully) have good and thoughtful copy for that (e.g. "There is a problem") and you'd have a direct correlation to what's already there, it would be good to use that. I think having some guidance about the copy would be really helpful. Changing e.g. "Message to alert the user to a problem goes here" which is currently in Elements to something clear and re-usable would be very helpful. Sounds like a good side project for some tech writers, if anyone finds the time. Those things must have been user tested before, haven't they? I don't think dynamically changing the page title would make much sense as I don't think it would be read again at any point? So, only doing this in the backend after the form has been submitted makes sense. Interesting about your NVDA version reacting differently. I'll try a few other versions and OS or browser combinations. It's not really important for this PR but interesting to know. |
selfthinker
force-pushed
the
reflect-error-in-title
branch
from
cb75315
to
4bfd72c
Compare
|
I have just adjusted the copy to not give a specific example except repeating whatever the error summary heading is. And I changed the page title of the two example forms from "Error in: " to "There was a problem - ". |
|
@selfthinker I would change that to "There is a problem" because the problem is in the present. I agree 100% agree about improving the language that is in elements. Hopefully what we or DWP produce can be added to elements and the service manual. I think we need to get rid of generic or placeholder content from elements and patterns wherever possible. |
selfthinker
force-pushed
the
reflect-error-in-title
branch
from
4bfd72c
to
4f7db35
Compare
|
Changing to "There is a problem" makes sense. I've just changed it. Yes, after HMRC and DWP researched their improvements, it would be great to have the results feed back to Elements to get rid of placeholder content. :) |
|
I have a personal preference to @StephenGill what do you think? |
|
I wouldn't concentrate on the exact content for the example pages, as their content is not great anyway and a bad example, especially for the page title. I would rather make improving that its own project.
Are you happy with that? If not, what would you change? |
selfthinker
force-pushed
the
reflect-error-in-title
branch
from
4f7db35
to
55082fe
Compare
|
We've had a meeting with @edwardhorsford and @StephenGill today and decided to go back to prefix the title with the most simple form: "Error: ". We've discussed what @stevenaproctor raised that it would imply blame. The general thinking was to make it as succinct and clear as possible. But Ed and Stephen will be better at explaining their reasoning... (Can you post a summary here?) I have just updated the code to reflect that decision, to rebase with master and to fix the conflict. |
Some points of the validation implementation advice were duplicated. This is rearranging and rephrasing them to merge them together.
This adds guidance to prefix the `title` with "Error: " to alert screen reader users as soon as possible that there has been an error after submitting a form. It also adds the required code to the two validation example forms. This was very successfully user-tested with screen reader users, with users actively pointing out how useful it is.
selfthinker
force-pushed
the
reflect-error-in-title
branch
from
55082fe
to
009d405
Compare
What problem does the pull request solve?
When a form submit wasn't successful and there are errors in the form which need to be highlighted, it is very important that every user is alerted to that as soon and effectively as possible. Although our solution for that is pretty good, it can still be improved.
Seeing users, even those with low vision, can see the big red box pretty clearly. Even in case they cannot read the text easily, they will know something is wrong. So, it's mostly the journey for blind screen reader users we should be concerned about.
Because we automatically focus on the error summary, some screen readers read that out pretty early, while others never read it. But what most screen readers read first is the title. That's what we can use to make them aware that there has been an error as soon as possible.
That's why this adds guidance to prefix the
titlewith something (like "Error in:"). It also adds the required code to the two validation example forms.This was very successfully user-tested with screen reader users, with users actively pointing out how useful it is.
It is also mentioned in the W3C's Web Accessibility Tutorial as a good practice example of how to notify users of interaction successes or failures. Changing the main heading would also be an option.
As some of the guidance was duplicated and overlapping a bit, this also moves it into a partial for re-use and rearranges some of its content.
One open question I still have is about the copy: Is "Error in: " a good example? I could also think of "Error - ". Who should I talk to to get feedback on that? What is our style?
How has this been tested?
This was tested in a couple of screen readers (always using the default configuration). All of these tests only reflect how they behave in case of a page with errors after a form post:
Those are the ones we care most about, but for completeness' sake, I have also tested:
role=alertWhen the title is not read, this change doesn't change anything. But when the title is read first, that's an improvement over being alerted about the error a couple of seconds later or never in case a user decides to quickly navigate somewhere else within the page.
What type of change is it?
Has the documentation been updated?